Jazeera Airways Information Technology Department

Table of Contents

1. Introduction 3

   1. Purpose 3

   2. API Testing Tools 3

   3. Intended Audience and Reading Suggestions 3

   4. Project Scope 3

   5. References 3

2. API DEVELOPMENT BEST PRACTICES 4

   1. Session Management 4

   2. Session Pooling 4

   3. Session Timeout 5

3. Overall Description 6

   1. Product Features 6

   2. User Classes and Characteristics 6

   3. Design and Implementation Constraints 6

   4. User Documentation 7

   5. Dependencies 7

4. General information 7

   1. Navitaire Digital API version information 7

   2. Pax Titles 7

   3. Logon information (Token) 7

   4. Password policy and reset 7

   5. IP Whitelisting 8

   6. Product Classes 8

   7. Aircraft Details 9

   8. Special Service Requests (SSRs) 9

   9. Infants 10

   10. Flight Seats 10

   11. TEST URLs 11

   12. Contact Us 11

5. Features 11

   1. New Booking 12

   2. Hold Booking 14

   3. Fare rules information 14

   4. Currency information 14

   5. Get baggage allowance 14

   6. Account related information 15

   7. Other Information 15

   8. Important Information 15

   9. Require Scenarios for certification 15

   10. Mange Booking Flow 70

   11. Service Bundle Feature 92

Appendix A: Glossary 106

Appendix B: Analysis Models 106

Appendix C: Issues List 106s

Revision History

1. ‌INTRODUCTION

   1. ‌Purpose

      Navitaire Digital API integration guide Use of Navitaire Digital API to

      
      

      1. Check flight availability

      2. Create new booking

      3. Add SSR

      4. Check seats availability and select seat during or after booking

      5. Add passenger’s documents

      6. Get fare rules

      7. Get account balance and make payments

      API Testing Tools

      Swagger (https://rtestupgrade.jazeeraairways.com/swagger)

      Postman (Using the OTA integration with postman file. This file will be attached among this documentation file and test cases).

      Intended Audience and Reading Suggestions

      Developers Business Managers UAT testers

      Project Scope

      Use of Navitaire Digital APIs for booking of Jazeera tickets

      References

      Navitaire documentation Navitaire knowledge base Navitaire support tool

   2. 
      

   3. 
      

   4. 
      

2. ‌API DEVELOPMENT BEST PRACTICES

   1. ‌Session Management

      Since New Skies requires a session for all API interactions, proper session management is paramount to performance. Applications should re-use sessions for repetitive functions of a single booking and explicitly call Logout at the end of processes to dispose of the session and free app server memory.

      New Skies requires that all consumers of the API logon to validate credentials, verify access level, and to instantiate the session that will be used throughout the subsequent interactions. The Logon method may seem lightweight, but in reality a series of lookups is happening in the background. This makes the Logon call one of the heavier calls from a processing standpoint. With this information in mind, it is best to make wise use of Logon by not needlessly logging on over and over for repetitive functions.

      The explicit use of Logout is also recommended to prevent unexpired (abandoned) sessions from building up and causing application degradation. To logout, use Token API with DELETE method. Refer to section 5.8.2 – point 16 for further details.

      Note: Repetitive calls to login API and excessive abandoned sessions can result in resource constraints and performance degradation.

      Each successful login (Token API call) is associated with one session. Within this one session, Availability API and BookingQuote API can be called multiple times, one call to TripSell API, add SSRs, pay the booking fully and confirm (commit) the booking to obtain the PNR. Then, Logout needs to be called to close the session.

      So, Token API should be called only in the following cases:

      1. Token expiration after idle time (15 minutes). Refer to section 2.3.

      2. After a booking cycle is finalized. That is, CommitBooking API is called and a corresponding recordLocater (PNR) is obtained with dueBalance = 0 (confirmed booking).

         If proceeding with a booking is not required after availability searches, logout API should be called.

         Over requesting: Unnecessary repetitive calls to login API specially and other APIs generally exhausts the server and slows response time. Hence, User ID would be blocked temporarily as a result if number of calls exceeds 200 calls per minute. The API integration should make wise use of login (Token) API and credible number of hits to other APIs.

         
         

   2. ‌Session Pooling

      The use of session pooling can reduce the number of individual sessions in memory. An effective session pool limits the number of sessions that can be used concurrently and employs a check- in/checkout system with the sessions. As sessions are freed up they can be checked-in and checked-out by other threads so as to limit the memory footprint on the app server. When all processing is done the sessions should be logged out, releasing them from memory.

      Search requests are stateless calls and do not need to be tied to a specific session. One call after another can be made on the same session without the need to call Clear or Logout. Reuse of sessions in this case can reduce stress on the system and prevent unnecessary session usage.

   3. ‌Session Timeout

      The current session timeout is 15 minutes. That is, the idle time between each two consecutive API calls. It’s showing in after generating the token.

      "idleTimeoutInMinutes": 15

      
      

3. ‌OVERALL DESCRIPTION

   1. ‌Product Features

      Check credit balance GetAvailability

      Three new Product Class codes have been created for Economy Class Cabin:

      Economy Cabin Product Class Codes,

      • EL (Economy Light)

      • EV (Economy Value)

      • EE (Economy Extra)

        Business Cabin Product Class Codes,

      • BU (Business) (Currently, it is only available for [KWI-CAI] and [CAI-KWI] flights)

        
        

        Sell segment/s Add payment

        • AG Payment Option

        • CC (Credit card) Payment Option

        • BSP Payment Option

          • BSP Cash

          • BSP Easy Pay

      Note: The Agent ID should be under IATA Organization ID to avail BSP Payment option.

      For testing BSP Payment in staging environment kindly note that the agency IATA ID should be registered under the IFG Test Environment.

      In case of no Test IATA ID available, please use the production credentials to make a test booking (using PAX name as test tester) and share the PNR for refund.

      Add comments Commit changes

      GetFareRules information

      
      

   2. ‌User Classes and Characteristics

      Online retail travel agents

      1. These travel agents sell multiple airline fares through their unique portal. Their target customers are:

         1. Direct customers

         2. Travel agents

      
      

   3. ‌Design and Implementation Constraints

      These are standard APIs that’s been used by a number of Navitaire airlines.
      Support below TLS 1.2 is discontinued
      The IP address that is used to access the API must be whitelisted by Navitaire

      
      

   4. ‌User Documentation

      Navitaire Digital API documentation FAQ
      Sample API test cases: a set of APIs that shows how API requests and responses are to make a booking for a different cases. It can be found attached to the OTA registration email.

      OTA Integration Postman Collection (A fast way to import APIs to a Postman Collection). It also can be found attached to the OTA registration email.

      
      

   5. ‌Dependencies

      This document is prepared with tests done using Swagger or Postman Navitaire API can be consumed using .NET, JAVA and other development tools

      
      

4. ‌GENERAL INFORMATION

   1. ‌Navitaire Digital API version information

      The current API version is 4.7.3

      
      

   2. ‌Pax Titles

      
      

      Title	Description
      MISS	Miss
      MR	Mr
      MRS	Mrs
      MS	Ms
      MSTR	Master
      CHD	Child

      
      

   3. ‌Logon information (Token)

      The Logon API is used to generate token (or session ID or signature). You will need username (agent ID or UserID) and password to generate the token. The domain code is “WW2” and the Channel type is “API”

      
      

   4. ‌Password policy and reset

      Password must be at least 6 characters, no more than 8 characters, only contain letters or numbers. The password cannot contain symbols.
      In case the account is locked or password expired or any other query related to your production credentials, please contact apisupport@jazeeraairways.com for further help

      
      

   5. ‌IP Whitelisting

      IPs must be whitelisted by Navitaire for access. Contact apisupport@jazeearaairways.com for this purpose.

      Product Classes

      Economy Cabin Product Classes

      Business Cabin Product Class (Currently, it is only available for [KWI-CAI] and [CAI-KWI] flights)

      Turnaround Time for IP whitelisting is 7 business days.

      
      

   6. 
      

      ECONOMY
      Fare Brand (Product Class)	Economy LIGHT – EL	Economy VALUE – EV	Economy EXTRA - EE
      Cabin Baggage	ADT,CHD - 7 KG/1 PIECE INFT - 10KG	ADT,CHD - 7 KG/1 PIECE INFT - 10KG	ADT,CHD - 7 KG/1 PIECE INFT - 10KG
      Checked Baggage**	NO BAGGAGE (* As per the weight received from system.)	20KG/1 PIECE (* As per the weight received from system.)	30KG/2 PIECES (* As per the weight received from system.)
      Purchase Baggage	Only available at Check-in	Pre-purchase 10KG online	Pre-purchase 10KG online
      Change	Pay to Change	Pay to Change	Pay to Change
      Cancellation	Non refundable	Pay to cancel up to 24 hours prior to departure	Pay to cancel up to 24 hours prior to departure

      
      

      BUSINESS
      Fare Brand (Product Class)	Business – BU
      Cabin Baggage	ADT,CHD - Total Weight 15 KG (2 PIECES) INFT - 10KG
      Checked Baggage**	60 KG/3 PIECES (* As per the weight received from system.)
      Purchase Baggage	Only available at Check-in
      Change	Pay to Change up to 3 hours of departure
      Cancellation	Pay to Cancel up to 3 hours of departure

      
      

      For more information about different classes and rules, refer to the following link: https://www.jazeeraairways.com/en-kw/plan/flight-information/fare-options

      ** Checked Baggage Allowance:

      Weight - should be displayed as per data received dynamically from the system. Use booking quote endpoint to get the baggage allowance from the system.

      
      

   7. ‌Aircraft Details

      We have two types of Aircraft:

      • A320 CEO

      • A320 NEO

      
      

   8. ‌Special Service Requests (SSRs) –

      SSRs are inventory controlled. SSRs will vary according to route and cabin/fare classes. Other restrictions may include seat and availability restrictions.

      It is important to read the SSRAvailability response to check if the SSR is available for the selected flight. Extra baggage can be booked 4 hours prior departure.

      Meal can be booked before 24 hours prior departure.

      SSR pricing is dynamic. It may depend on the sector, travel date, TA ID or service bundles selected. For the connecting sectors, pass SSR separately for each leg.

      For extra baggage use ssrType BaggageAllowance; extra baggage SSR limited to 1 per PAX per sector.

      Extra baggage not available for Economy Light (EL)

      For the connection sector booking, Extra baggage (XB10) should be added for both the segments. For meals use ssrType Meal.

      LOUN available only for flights departing from Kuwait. LOUN can be assigned for both the Adult (ADT) passenger and child (CHD) passenger. LOUN is limited to 1 per passenger.

      PRRT is limited to 1 per passenger.

      
      

      Available SSRs:

      1. Meals

      2. Pearl Lounge Service

         
         

         SSR Code	Name
         LOUN	Pearl Lounge Service at KWI T5

      3. PRIORITY Check-in

         SSR Code	Name
         PRRT	PRIORITY Check-in, Boarding and Baggage

      4. Extra baggage

      SSR Code	Name
      XB10	Extra Baggage 10 KG

      
      

      For more details refer the following links: https://www.jazeeraairways.com/en-kw/plan/book/jazeera-cafe

      https://www.jazeeraairways.com/en-kw/experience/at-the-airport/jazeera-lounge

      https://www.jazeeraairways.com/en-kw/plan/book/priority-service

      
      

   9. ‌Infants

      
      

      Infants are considered SSRs. To check possibility of adding them and the related fair, use

      BookingQuote API and set the value of “infantsCount”.

      Add infants to reservations by setting the value of “infantsCount” in TripSell API.

      After adding infants to a reservation, related data need to be added in Passenger request API as shown below:

      
      

   10. ‌Flight Seats

       Seats can be optionally reserved as a part of the reservation process. After booking a flight using TripSell API, check availability of seats using SeatsAvailabilityBySegment API. Pass segmentKey (the one used in booking the flight). Make sure to check the “availability” node value (an integer represents seat availability and must have value of 5). Also, get the unitKey of the desired seat.
       Availability of seats may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3- 'HeldForAnotherSession', 4-'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8- 'FleetBlocked', 9-'Restricted', 10-'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.
       Add the seat to the booking using seatAssignment API. Use the “unitKey” acquired form seat availability API.

   11. ‌TEST URLs

       URLs: https://rtestupgrade.jazeeraairways.com/swagger

       OTA Login credentials will be shared once finalized the agreement

       
       

   12. ‌Contact Us

       Please refer to this documentation and to OTA Navitaire Digital API integration FAQ document as an immediate reference point. For IP Whitelisting and technical queries that are not mentioned inprevious references, contact apisupport@jazeeraairways.com. The usual response time for all non-production emergency services is up to 3 business days.

       For NDA signing, OTA registration and Credential related queries, contact apiregister@jazeeraairways.com . The usual response time for all non-production emergency services is up to 3 business days.

       A production emergency occurs when an integration that was working on production, doesn’t work leading to 100% booking failures.

       
       

5. ‌FEATURES

   The booking methods retrieve data, modify booking state, or add a booking in the database. The session created when a user logs on contains a booking state that is used through creating, modifying getting the booking.

   Methods such as AddPaymentToBooking and CommitBooking modify the booking state. The methods that update the booking state usually return responses that indicate success or failure of the method and may contain data needed in subsequent steps. Methods such as BookingDetails, AvailableSSRs and Availability retrieve data. The BookingCommit method is used to finalize a booking by combining the data contained in a booking commit request with the booking data in booking state and if there are no errors writes it to the database.)

   
   

   Sample Tasks:

   • Create new bookings

   • Find bookings by multiple criteria

   • Get inventory availability and pricing

   • Get SSR availability and pricing

   1. ‌New Booking

      The basic API call sequence required to make a booking (using AG Account) is as the following:

      1. Acquire a token (login)

      2. Check flight availability

      3. Sell a trip

      4. Add passenger and contact information

      5. Add payment to booking

      6. Commit booking (to obtain PNR or recordLocator)

      7. Get booking status (to check the booking status whether it is confirmed/hold/failed)

      8. Logout

      
      

      The basic API call sequence required to make a booking (using BSP Payment) is as the following:

      1. Acquire a token (login)

      2. Check flight availability

      3. Sell a trip

      4. Add passenger and contact information

      5. Commit booking (to obtain PNR or recordLocator)

      6. Get booking status (to check the booking status whether it is confirmed/hold/failed)

      7. Make BSP Payment

         • BSP Cash

         • BSP Easy Pay

      8. Get booking status (to check the booking status whether it is confirmed/hold/failed)

      9. Logout

      The basic API call sequence required to make a booking (using Credit Card (CC) Payment) is as the following:

      1. Acquire a token (login)

      2. Check flight availability

      3. Sell a trip

      4. Add passenger and contact information

      5. Commit booking (to obtain PNR or recordLocator)

      6. Get booking status

      7. Make CC (Credit card) payment

      8. Get booking status (to check the booking status whether it is confirmed/hold/failed)

      9. Logout

      
      

      The following APIs are optional and can be called optionally as needed:

      1. Booking Quote (for fare breakdown, Infant fare & baggage info)

      2. Get passengers

      3. Add passenger travel document

      4. Get SSRs

      5. Add SSRs

      6. Get seat availability by segment

      7. Assign seat

      8. Check organization account balance (Agency Credit)

      9. Get booking status (to check the booking status whether it is confirmed/hold/failed)

      10. Currency Converter

      
      

   2. ‌Hold Booking

      The basic API call sequence required to make a hold booking (using only AG Account) is as the following:

      1. Acquire a token (login)

      2. Check flight availability

      3. Sell a trip

      4. Add passenger and contact information

      5. Get Available Hold Date

      6. Add Hold Fees (For all passengers)

      7. Add payment (Hold Fee) to the booking (with deposit flag as true)

      8. Commit booking (to obtain PNR or record Locator) by passing the above hold expiration date. Note: Please pass the header confirmHoldBooking as true.

      9. Get booking status (to check the booking status whether it is confirmed/hold/failed)

      10. Logout

      
      

      The following APIs are required to complete the Hold booking within the hold period time.

      1. Acquire a token (login)

      2. Retrieve the booking using PNR/Record locator

      3. Check the balance due on the booking

      4. Add Payment to booking

      5. Commit booking

      6. Get booking status (to check the booking status whether it is confirmed/hold/failed)

      7. Logout

      
      

      The following APIs are optional and can be called optionally as needed:

      1. Booking Quote (for fare breakdown, Infant fare & baggage info)

      2. Get passengers

      3. Add passenger travel document

      4. Get SSRs

      5. Add SSRs

      6. Get seat availability by segment

      7. Assign seat

      8. Check organization account balance (Agency Credit)

      9. Get booking status (to check the booking status whether it is confirmed/hold/failed)

      10. Currency Converter

      
      

   3. ‌Fare rules information

      You can retrieve the fare rules based on Farekey (fareAvailabilityKey).

      
      

   4. ‌Currency information

      Currency Converter – this method helps to convert currency based on currency code.

      Currency Information – this method helps to give the information of all currencies configured in system along with currency code, display digits and description.

      
      

   5. ‌Get baggage allowance

      The baggage allowance configured based on fare rules Will get the information using “Booking Quote” method.

   6. ‌Account related information

      Organization Account
      Organization Account Transaction

      
      

   7. ‌Other Information (Resources)

      Stations Cities Countries

      Sector Based Message Station Local Time

      
      

   8. ‌Important Information

      Source Organization Should be your organization code so that booking reflects to your account. Meal & Seat configured based on leg and other SSR’s configured based on journey.

      Passenger Details and Passenger Contact are added in the same request.

      Fare break up is available in booking quote method. Which is nothing but Price Itinerary Request. It is possible to add multiple pairs of fareAvailabilityKey and journeyKey in the same request.

      Always use the culture as “en-GB” in Contact request.

      Use the organization ID in your passenger contact request ("sourceOrganization": “Agency Organization ID”) & payment requests ("ACCTNO": "Agency Organization ID ")

      For the Jazeera Itinerary add the tag “distribution = ‘Email” in passengercontact method.

      Itinerary sending option can be controlled from booking commit request by setting “notifyContacts”- true/false.

      Itinerary sending option is disabled in production and the itinerary emails will be triggered only from TEST environment.

      Use CompressionType": "CompressByProductClass" in availability request to get the fare bundles (Economy Light, Value & Extra)

      
      

   9. ‌Require Scenarios for certification

One Way, Roundtrip, Connecting Booking – 2 ADT, 2 CHD, 1 INFT

1. Payment with Agency account (AG) or Card

2. Product Class - Economy Light (EL), Economy Value (EV) and Economy Extra (EE)

3. Passenger qty. should be less than or equal to 9

4. Add SSR like, Meal, Baggage (Extra baggage should be added to both segments of connecting flights)

1. ‌Booking Flow (For AG Account)

   The following information describes the steps used to make a booking. Refer to section 5.1 (New Booking) to check the basic and mandatory steps to make a booking. Remaining APIs are optional and can be used if needed. Also, for each API, check its corresponding test case (in the test cases file attached to OTA registration email) in-order-to see its request body and the corresponding successful response.

   1. Get Token – Creates the general access token that will grant access to the API. Token idle time out is 15 minutes. That is, the token will expire if idle time between each two consecutive API calls is greater than or equal to 15 minutes.

      Token API should be used wisely as each successful login is associated with one session. Please refer to section 2.1 for best practices regarding session management and avoiding resource leaking.

      Successful Token API request and response looks similar to the following (refer to test cases attached in the organization registration email for full examples including request body and header data (using Postman or Swagger). Agents may require whitelisting server IP address.

      
      

   2. Get Availability – Searches for flights with the full availability search request. This request allows for total control over the configuration or criteria. If a property is not set, default values will be set instead. These defaults are what we consider a general optimized request. If these optimizations are not preferred the requester will need to opt out the filters on the availability request.

      Note: You'll always receive the fares in availability response in origin station default currency regardless of which currency you pass in the request. All the remaining API call requests (BookingQuote, TripSell, BookingCommit, etc) need to use the currency specified in the availability API response. If you want to display fares for customer in any other currency, use currency conversion API.

      Pass AgentID (UserID) in the availability request header to get the availability response.

      
      

      The default values that will be set unless specified:

      
      

      • TaxesAndFees = TaxesAndFeesRollupMode.None

      • Criteria.SsrCollectionsMode = AvailabilitySsrCollectionsMode.None

      • Criteria.Filters.FareInclusionType = AvailabilityType.Default

      • Criteria.Filters.CompressionType = FareClassControl.LowestFareClass

      • Criteria.Filters.Loyalty = LoyaltyFilter.MonetaryOnly

      • Criteria.Filters.FlightType = FlightType.All

      • Criteria.Filters.ExclusionType = AvailabilityFilter.ExcludeUnavailable

      • Criteria.Filters.SortOptions =

        JourneySortKey.LowestFare, JourneySortKey.EarliestDeparture, JourneySortKey.ShortestTravelTime

      • Filters.ConnectionType = SoldAsConnectionType.None

      • Criteria.Filters.MaxConnectingFlights = 0

      • Criteria.Stations.SearchDestinationMacs = false

      • Criteria.Stations.SearchOriginMacs = false

      • Criteria.Filters.BundleControlFilter = BundleControlFilter.Disabled

      • NumberOfFaresPerJourney = 1

      Successful Availability API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

      
      

   3. Booking Quote (Price Itinerary) - Retrieves fare breakdown, baggage allowance and infant fare based on the request. You will get full value including tax of the each component.

The availability response will only return adult and child fares. When infants are added to a flight search, it is necessary to use the booking quote response to obtain the fares.

Baggage allowance information can also be obtained from the booking quote response.

Pass AgentID in the Booking quote request header to get the response. You can pass one or multiple pairs of journeyKey and fareAvailabilityKey in a single booking quote request. So, round trips, connecting flights or multiple flights can be queried in a single booking quote API request (Ex. for both inbound and outbound flights). Duplicate journeykey is not allowed in a request. Calling this API is optional and not necessarily happens after each availability request unless the information returned by it is required (infants fare, baggage allowance, fare breakdown …etc.).

resulting from URL length issues. Successful BookingQuote API request and response looks

similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

4. Trip Sell - Sells the list of journeys and creates a booking if it doesn't already exist. You can sell

the infant using this method. Roundtrips must include journeyKey and fareAvailabilityKey of both outbound and return flights in the same API call.

Pass AgentID in the Trip Sell request header to get the Trip Sell response. Successful TripSell API request and response looks similar to the following:

Note: Although this endpoint behaves like a GET, POST is used to reduce the limitations

5. Add Passenger and Contact Info (Passengers API) – Update the booking passenger(s) information and contact details based on the passenger key.

Use can use the agency contact information to update the contact details.

Pass AgentID in the Add Passenger and contact request header to get the Add Passenger and contact response. Successful Passengers API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

6. Get Passengers – Get the collection of passenger(s) on the booking along with passengerkey. Successful GetPassengers API request and response looks similar to the following:

7. Seats Availability by segment- checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling TripSell) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:

Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.

The “availability” key is a single digit and it represents the availability of the seat. It may have

the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.

For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.

Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.

8. Seat Assignment- As the name suggests, it assigns a seat for a passenger. The API takes

segmentKey (the journeyKey of the journey you wish to assign seat(s) in it) as a parameter. The request body must include the unitkey (obtained by calling get seatsAvailabilityBySegment API) and the passengerkey (obtained by calling GetPassengers API). Successful GetPassengers API request and response looks similar to the following:

1. Get Available SSRs– To get all the available SSRs. Returned SSRs are classified under journey, segment and leg SSRs. It is important to check this API before adding SSRs since some SSRs may not be available on some airports or even within the same flight (Ex. Due to seat restrictions). Also, you will need to acquire the SSRKey of the SSR (in case it is available) form this API in order to use it in SellSSR API as shown below:

   
   

   Successful AvailableSSRs API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

   
   

2. Add SSRs (SellSSR) –To add the required SSRs. For connected flights, an SSR need to be available and added to all segments if passenger requested to have SSR on the full flight. For some SSRs (like extra baggage XB10 or XB20), it is a must to have the SSR on both segments. In the request body, use the SSRKey obtained in get AvailableSSRs API. Successful SellSSR API request and response looks similar to the following:

   
   

   For the Meals SSRs, ssrKey is available under legSsrs tag as below

   • Check response from /api/jz/v1/Booking/AvailableSSRs,

     
     

   • For the connecting sectors, for meals pass SSR separately for each leg. To get SSRs available for each leg, take response from /api/jz/v1/Booking/AvailableSSRs, check SSRs available for each leg and pass SSRs accordingly,

• SSRs like Extra baggage (XB10), PRRT can get from /api/jz/v1/Booking/AvailableSSRs response under journeySsrs for each passenger ssrKey is available.

  • In case of connection booking, the SSRs like XB10 and PRRT will be added for the whole journey, so it will be applied for both sectors.

  • In the below figure for XB10, name (highlighted) in the figure below can be taken to display the SSR name for XB10 SSR.

• Passenger Availability can check in the /api/jz/v1/Booking/AvailableSSRs response as below. In the figure below we can see the SSR key for TSML (SSR) for the passenger key MCFBRFQ-

• For the LOUN corresponding ssrKey is available under segmentSsrs tag in the

/api/jz/v1/Booking/AvailableSSRs response.

11. Add passenger travel Documents: Use PassengerTravelDocument API to add the passport details. “issuedByCode” is a two letters country code represents passport issued country (Ex. “IN” stands for India) and “number” is represents passport number. Set “documentTypeCode” to “PASS” for passport as shown below or set it to be “I” for CivilID.

Adding travelling document is an optional step and it can be done during check-in process. Successful PassengerTravelDocument API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

1. Check Agency account balance – To make sure the agency account has sufficient account balance to make the payment/booking. The response will contain the below:

   
   

   
   

2. Add payment to booking – Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.

   
   

   Adding any paid services need to have corresponding payment added. To pay in full, take amount (balance due) from booking details API and pass it in the Add Payment request.

   In Swagger,

   
   

   Pass AgentID in the Add Payment request header and pass your organization ID as a value for ACCTNO. Over or underpayment is not allowed and committing the booking will not succeed is such case. Successful AddPaymentToBooking APIrequest and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

   
   

3. Commit Booking - Commits stateful changes made and finalize the booking. In case of overpayments or underpayments, commit booking API will not succeed. The amount paid

   should match to the due

Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.

Itinerary sending option can be controlled from booking commit request by setting “notifyContacts”- true/false.

Itinerary sending option is disabled in production and the itinerary emails will be triggered only from TEST environment.

This feature will be enabled the production environment, upon request from the agency. Pass AgentID in the commit booking request header. Successful AddPaymentToBooking API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples). The PNR (recordLocator) will be included the response of this API)

1. Get Booking Status-To get the booking and payments status.

   /api/jz/v1/BookingDetails

   Pass BookingDetailsType value as BalanceDue.

   For confirmed bookings and in BookingDetails API response:

   1. status should be “Confirmed”.

   2. paidStatus should be ”PaidInFull”.

   3. balanceDue should be zero as shown below:

16. Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

‌

The following information describes the steps used to make a booking using BSP Payment. Refer to section 5.1 (New Booking) to check the basic and mandatory steps to make a booking using BSP Payment. Remaining APIs are optional and can be used if needed. Also, for each API, check its corresponding test case (in the test cases file attached to OTA registration email) in-order-to see its request body and the corresponding successful response.

1. Get Token – Creates the general access token that will grant access to the API. Token idle time out is 15 minutes. That is, the token will expire if idle time between each two consecutive API calls is greater than or equal to 15 minutes.

   Token API should be used wisely as each successful login is associated with one session. Please refer to section 2.1 for best practices regarding session management and avoiding resource leaking.

   Successful Token API request and response looks similar to the following (refer to test cases attached in the organization registration email for full examples including request body and header data (using Postman or Swagger). Agents may require whitelisting server IP address.

   
   

2. Get Availability – Searches for flights with the full availability search request. This request allows for total control over the configuration or criteria. If a property is not set, default values will be set instead. These defaults are what we consider a general optimized request. If these optimizations are not preferred the requester will need to opt out the filters on the availability request.

   Note: You'll always receive the fares in availability response in origin station default currency regardless of which currency you pass in the request. All the remaining API call requests (BookingQuote, TripSell, BookingCommit, etc) need to use the currency specified in the availability API response. If you want to display fares for customer in any other currency, use currency conversion API.

   Pass AgentID (UserID) in the availability request header to get the availability response.

   
   

   The default values that will be set unless specified:

   
   

   • AvailabilityRequestv2.TaxesAndFees = TaxesAndFeesRollupMode.TaxesAndFees

   • AvailabilityRequestv2.Criteria.SsrCollectionsMode = AvailabilitySsrCollectionsMode.None

   • AvailabilityRequestv2.Criteria.Filters.FareInclusionType = AvailabilityType.Default

   • AvailabilityRequestv2.Criteria.Filters.CompressionType = FareClassControl.LowestFareClass

   • AvailabilityRequestv2.Criteria.Filters.Loyalty = LoyaltyFilter.MonetaryOnly

   • AvailabilityRequestv2.Criteria.Filters.FlightType = FlightType.All

   • AvailabilityRequestv2.Criteria.Filters.ExclusionType = AvailabilityFilter.ExcludeUnavailable

   • AvailabilityRequestv2.Criteria.Filters.SortOptions = JourneySortKey.LowestFare,JourneySortKey.EarliestDeparture,JourneySortKey.ShortestTravelTime

   • AvailabilityRequestv2.Filters.ConnectionType = SoldAsConnectionType.None

   • AvailabilityRequestv2.Criteria.Filters.MaxConnectingFlights = 0

   • AvailabilityRequestv2.Criteria.Stations.SearchDestinationMacs = false

   • AvailabilityRequestv2.Criteria.Stations.SearchOriginMacs = false

   • AvailabilityRequestv2.NumberOfFaresPerJourney = 1

   
   

   Successful Availability API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

   
   

3. Booking Quote (Price Itinerary) - Retrieves fare breakdown, baggage allowance and infant fare based on the request. You will get full value including tax of the each component.

   The availability response will only return adult and child fares. When infants are added to a flight search, it is necessary to use the booking quote response to obtain the fares.

   Baggage allowance information can also be obtained from the booking quote response.

   Pass AgentID in the Booking quote request header to get the response. You can pass one or multiple pairs of journeyKey and fareAvailabilityKey in a single booking quote request. So,

   round trips, connecting flights or multiple flights can be queried in a single booking quote API request (Ex. for both inbound and outbound flights). Duplicate journeykey is not allowed in a request. Calling this API is optional and not necessarily happens after each availability request unless the information returned by it is required (infants fare, baggage allowance, fare breakdown …etc.).

   Note: Although this endpoint behaves like a GET, POST is used to reduce the limitations resulting from URL length issues. Successful BookingQuote API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

   
   

4. Trip Sell - Sells the list of journeys and creates a booking if it doesn't already exist. You can sell the infant using this method. Roundtrips must include journeyKey and fareAvailabilityKey of both outbound and return flights in the same API call.

   Pass AgentID in the Trip Sell request header to get the Trip Sell response. Successful TripSell API request and response looks similar to the following:

   
   

5. Add Passenger and Contact Info (Passengers API) – Update the booking passenger(s) information and contact details based on the passenger key.

   Use can use the agency contact information to update the contact details.

   Pass AgentID in the Add Passenger and contact request header to get the Add Passenger and contact response. Successful Passengers API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

   Note: Please make sure to pass the correct organization Id to the field “sourceOrganization”

   
   

6. Get Passengers – Get the collection of passenger(s) on the booking along with passengerkey. Successful GetPassengers API request and response looks similar to the following:

7. Seats Availability by segment- checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling TripSell) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:

Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.

The “availability” key is a single digit and it represents the availability of the seat. It may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.

For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.

Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.

8. Seat Assignment- As the name suggests, it assigns a seat for a passenger. The API takes segmentKey (the journeyKey of the journey you wish to assign seat(s) in it) as a parameter. The request body must include the unitkey (obtained by calling get seatsAvailabilityBySegment API) and the passengerkey (obtained by calling GetPassengers API). Successful GetPassengers API request and response looks similar to the following:

9. Get Available SSRs– To get all the available SSRs. Returned SSRs are classified under journey,

segment and leg SSRs. It is important to check this API before adding SSRs since some SSRs may not be available on some airports or even within the same flight (Ex. Due to seat restrictions). Also, you will need to acquire the SSRKey of the SSR (in case it is available) form this API in order to use it in SellSSR API as shown below:

Successful AvailableSSRs API request and response looks similar to the following (refer to test

cases attached to the organization registration email for full APIs examples):

10. Add SSRs (SellSSR) –To add the required SSRs. For connected flights, an SSR need to be available and added to all segments if passenger requested to have SSR on the full flight. For some SSRs (like extra baggage XB10 or XB20), it is a must to have the SSR on both segments. In the request body, use the SSRKey obtained in get AvailableSSRs API. Successful SellSSR API request and response looks similar to the following:

• For the Meals SSRs, ssrKey is available under legSsrs tag as below

  • Check response from /api/jz/v1/Booking/AvailableSSRs,

    
    

  • For the connecting sectors, for meals pass SSR separately for each leg. To get SSRs available for each leg, take response from /api/jz/v1/Booking/AvailableSSRs, check SSRs available for each leg and pass SSRs accordingly,

    
    

• SSRs like Extra baggage (XB10), PRRT can get from /api/jz/v1/Booking/AvailableSSRs response under journeySsrs for each passenger ssrKey is available.

  • In case of connection booking, the SSRs like XB10 and PRRT will be added for the whole journey, so it will be applied for both sectors.

  • In the below figure for XB10, name (highlighted) in the figure below can be taken to display the SSR name for XB10 SSR.

• Passenger Availability can check in the /api/jz/v1/Booking/AvailableSSRs response as below. In the figure below we can see the SSR key for TSML (SSR) for the passenger key MCFBRFQ-

• For the LOUN corresponding ssrKey is available under segmentSsrs tag in the

/api/jz/v1/Booking/AvailableSSRs response.

11. Commit Booking - Commits stateful changes before making BSP payment. The booking will be

12. Get Booking Status-To get the booking and payments status.

/api/jz/v1/BookingDetails

Pass BookingDetailsType value as BalanceDue.

The booking will be on “Hold” and the payment status will be “UnderPaid”.

1. BSP Payment– Add the payment using BSP Payment.

   1. BSP Cash:

      TEST URL: https://stg-mapi.jazeeraairways.com/api/jz/ota/bspcash/pay

      
      

      Headers: Make sure the authorization is provided in the header.

      
      

      Request Body:

      {

      
      

      }

      
      

      "serviceType": "Dotrez", "paymentType": "BSPCASH", "accountNumber": ""

      Success response: The BSP payment will return success - true in case if the payment is successful and the booking will also be confirmed.

      In order to check the booking confirmation please use the Get Booking Status API Request as per point no: 14.

      
      

      
      

      Failure response:

      The BSP payment will return success - false in case if the payment is

      not successful and the booking will not be confirmed. It will remain on hold for 15 minutes

      and then the booking will get hold- Cancelled.

      2. BSP Easy Pay:

      TEST URL: https://stg-mapi.jazeeraairways.com/api/jz/ota/bspcash/pay

      
      

      Headers: Make sure the authorization is provided in the header.

      Request Body:

      {

      "serviceType": "Dotrez", "paymentType": "EASYPAY",

      "accountNumber": "Ecd4pnJRG27hcVRq/Ku01FNkVJf/9MF85mN0FufGRRp4Gu ouloS0eH//WRprehKOjliz5iqVkWSCGUWIP6SQWeIVD63RHMd0+1N/HZoLOVY0HWYU uJQt02lx//ldo6vOQINe7wdPEcN9qgwpDlFcHVBV2kVVWpo0lEhnvZmV5Wts3Vm5Pn saT3t6m3HKE/aChFDNV+4vYUAiOBqXBPR42fKmlbFQ9NyXPU4FoCfyoKY9sEL1m4n2 7+RZwgQL8ttgGdr7HyPQkgA2AFa5au+/B+0+Fk1wik5aBhPscPh/08xjabY7myoH1L 6ldIZ8MNc/+VFdTw=="

      }

      Note:

      The above highlighted part accountNumber is an encrypted string consisting of account Number and expiry date.

      Kindly construct ‘account Number’ and ‘expiry date’ in the JSON format as –

      {

      "accountNumber":"169898803734295", "expiryDate"":"0223"

      }

      
      

      and encrypt using RSA algorithm with the public key. The public key will be shared in separate mail on request.

      Success response: The BSP payment will return success - true in case if the payment is successful and the booking will also be confirmed.

      In order to check the booking confirmation please use the Get Booking Status API Request as per point no: 14.

      
      

      Failure response: The BSP payment will return success - false in case if the payment is not successful and the booking will not be confirmed. It will remain on hold for 15 minutes and then the booking will get hold- Cancelled.

      
      

      1. Get Booking Status-To get the booking and payments status.

         /api/jz/v1/BookingDetails

         Pass BookingDetailsType value as BalanceDue.

         For confirmed bookings and in BookingDetails API response:

         1. status should be “Confirmed”.

         2. paidStatus should be ”PaidInFull”.

         3. balanceDue should be zero as shown below:

      For unsuccessful (Failed) payments, the BookingDetails API response is as below:

      1. status will be “Hold”.

      2. paidStatus will be ”UnderPaid”.

      3. balanceDue will be same booking amount.

         
         

         1. Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

         
         

         ‌

         Booking Flow (For Credit Card (CC) Payment)

         The following information describes the steps used to make a booking using CC Payment. Refer to section 5.1 (New Booking) to check the basic and mandatory steps to make a booking using CC Payment. Remaining APIs are optional and can be used if needed. Also, for each API, check its corresponding test case (in the test cases file attached to OTA registration email) in-order-to see its request body and the corresponding successful response.

         1. Get Token – Creates the general access token that will grant access to the API. Token idle time out is 15 minutes. That is, the token will expire if idle time between each two consecutive API calls is greater than or equal to 15 minutes.

            Token API should be used wisely as each successful login is associated with one session. Please refer to section 2.1 for best practices regarding session management and avoiding resource leaking.

            Successful Token API request and response looks similar to the following (refer to test cases attached in the organization registration email for full examples including request body and header data (using Postman or Swagger). Agents may require whitelisting server IP address.

            
            

         2. Get Availability – Searches for flights with the full availability search request. This request allows for total control over the configuration or criteria. If a property is not set, default values will be set instead. These defaults are what we consider a general optimized request. If these optimizations are not preferred the requester will need to opt out the filters on the availability request.

            Note: You'll always receive the fares in availability response in origin station default currency regardless of which currency you pass in the request. All the remaining API call requests (BookingQuote, TripSell, BookingCommit, etc) need to use the currency specified in the availability API response. If you want to display fares for customer in any other currency, use currency conversion API.

            • AvailabilityRequestv2.TaxesAndFees = TaxesAndFeesRollupMode.TaxesAndFees

            • AvailabilityRequestv2.Criteria.SsrCollectionsMode = AvailabilitySsrCollectionsMode.None

            • AvailabilityRequestv2.Criteria.Filters.FareInclusionType = AvailabilityType.Default

            • AvailabilityRequestv2.Criteria.Filters.CompressionType = FareClassControl.LowestFareClass

            • AvailabilityRequestv2.Criteria.Filters.Loyalty = LoyaltyFilter.MonetaryOnly

            • AvailabilityRequestv2.Criteria.Filters.FlightType = FlightType.All

            • AvailabilityRequestv2.Criteria.Filters.ExclusionType = AvailabilityFilter.ExcludeUnavailable

            • AvailabilityRequestv2.Criteria.Filters.SortOptions = JourneySortKey.LowestFare,JourneySortKey.EarliestDeparture,JourneySortKey.ShortestTravelTime

            • AvailabilityRequestv2.Filters.ConnectionType = SoldAsConnectionType.None

            • AvailabilityRequestv2.Criteria.Filters.MaxConnectingFlights = 0

            • AvailabilityRequestv2.Criteria.Stations.SearchDestinationMacs = false

            • AvailabilityRequestv2.Criteria.Stations.SearchOriginMacs = false

            • AvailabilityRequestv2.NumberOfFaresPerJourney = 1

            
            

            Successful Availability API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

            Pass AgentID (UserID) in the availability request header to get the availability response. The default values that will be set unless specified:

         3. Booking Quote (Price Itinerary) - Retrieves fare breakdown, baggage allowance and infant fare based on the request. You will get full value including tax of the each component.

            The availability response will only return adult and child fares. When infants are added to a flight search, it is necessary to use the booking quote response to obtain the fares.

            Baggage allowance information can also be obtained from the booking quote response.

            Pass AgentID in the Booking quote request header to get the response. You can pass one or multiple pairs of journeyKey and fareAvailabilityKey in a single booking quote request. So, round trips, connecting flights or multiple flights can be queried in a single booking quote API request (Ex. for both inbound and outbound flights). Duplicate journeykey is not allowed in a request. Calling this API is optional and not necessarily happens after each availability request unless the information returned by it is required (infants fare, baggage allowance, fare breakdown …etc.).

            
            

            Note: Although this endpoint behaves like a GET, POST is used to reduce the limitations resulting from URL length issues. Successful BookingQuote API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

            
            

         4. Trip Sell - Sells the list of journeys and creates a booking if it doesn't already exist. You can sell the infant using this method. Roundtrips must include journeyKey and fareAvailabilityKey of both outbound and return flights in the same API call.

            Pass AgentID in the Trip Sell request header to get the Trip Sell response. Successful TripSell API request and response looks similar to the following:

            
            

         5. Add Passenger and Contact Info (Passengers API) – Update the booking passenger(s) information and contact details based on the passenger key.

            Use can use the agency contact information to update the contact details.

            Pass AgentID in the Add Passenger and contact request header to get the Add Passenger and contact response. Successful Passengers API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

            Note: Please make sure to pass the correct organization Id to the field “sourceOrganization”

            
            

         6. Get Passengers – Get the collection of passenger(s) on the booking along with passengerkey. Successful GetPassengers API request and response looks similar to the following:

         7. Seats Availability by segment- checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling TripSell) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:

            
            

            Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.

            
            

            The “availability” key is a single digit and it represents the availability of the seat. It may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.

            For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.

            Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.

            
            

         8. Seat Assignment- As the name suggests, it assigns a seat for a passenger. The API takes segmentKey (the journeyKey of the journey you wish to assign seat(s) in it) as a parameter. The request body must include the unitkey (obtained by calling get seatsAvailabilityBySegment API) and the passengerkey (obtained by calling GetPassengers API). Successful GetPassengers API request and response looks similar to the following:

         
         

         9. Get Available SSRs– To get all the available SSRs. Returned SSRs are classified under

         journey, segment and leg SSRs. It is important to check this API before adding SSRs since some SSRs may not be available on some airports or even within the same flight (Ex. Due to seat restrictions). Also, you will need to acquire the SSRKey of the SSR (in case it is available) form this API in order to use it in SellSSR API as shown below:

         Successful AvailableSSRs API request and response looks similar to the following (refer to test

         cases attached to the organization registration email for full APIs examples):

         
         

         10. Add SSRs (SellSSR) –To add the required SSRs. For connected flights, an SSR need to be available and added to all segments if passenger requested to have SSR on the full flight. For some SSRs (like extra baggage XB10 or XB20), it is a must to have the SSR on both segments. In the request body, use the SSRKey obtained in get AvailableSSRs API. Successful SellSSR API request and response looks similar to the following:

         
         

         • For the Meals SSRs, ssrKey is available under legSsrs tag as below

           • Check response from /api/jz/v1/Booking/AvailableSSRs,

             
             

           • For the connecting sectors, for meals pass SSR separately for each leg. To get SSRs available for each leg, take response from /api/jz/v1/Booking/AvailableSSRs, check SSRs available for each leg and pass SSRs accordingly,

             
             

         • SSRs like Extra baggage (XB10), PRRT can get from /api/jz/v1/Booking/AvailableSSRs response Under journeySsrs for each passenger ssrKey is available.

           • In case of connection booking, the SSRs like XB10 and PRRT will be added for the whole journey, so it will be applied for both sectors.

           • In the below figure for XB10, name (highlighted) in the figure below can be taken to display the SSR name for XB10 SSR.

         
         

         • Passenger Availability can check in the /api/jz/v1/Booking/AvailableSSRs response as below. In the figure below we can see the SSR key for TSML (SSR) for the passenger key MCFBRFQ-

         • For the LOUN corresponding ssrKey is available under segmentSsrs tag in the

         /api/jz/v1/Booking/AvailableSSRs response.

         
         

         11. Commit Booking - Commits stateful changes before making BSP payment. The booking

         12. Get Booking Status-To get the booking and payments status.

         /api/jz/v1/BookingDetails

         will be in Hold for 15 minutes until the BSP payment is completed.

Pass BookingDetailsType value as BalanceDue.

The booking will be on “Hold” and the payment status will be “UnderPaid”.

13. CC Payment– Add the payment using CC Payment.

GET TEST URL:

Query Parameters:

returnUrl="website return url after payment",

paymentMethod="CreditCard/CreditCard_Amex/Payu"

Headers: Make sure the authorization is provided in the header.

Success Response:

Steps for CC (Credit Card) payment success or failure check:

1. The CC payment will return a URL which has to be used for making the payments.

2. Once the payment is competed the page navigates to the returnURL page which was provided as query param.

   Below sample return URL:

   
   

   https://test.com/TestForCC?order_no=W4KPYV63812345116584483&session_id=473c3 63d485bea9eb246a74ea7104a6242a7d440&reference_number=R7353&expiry_date=& data=eyJ0b2tlbiI6ImV5SmhiR2NpT2lKSVV6STFWNDSTZJa3BYVkNKOS5leUp6ZFdJaU9pSlB WRUVpTENKcWRHa2lPURZNFppMWhZMkpqTmpRM04yWTJPVGNpTENKcGMzTWlPaUp rYjNSU1JWb2dHVSNWo0bm1XQnU5TGYzbnM4Q3pfNFBzX2RjRGxHU002bHQ2UEEiLCJib

   29raW5nQW1vdW50IjoiNzIuOTYiLCJib29raW5nQ3VycmVuY3kiOiJLV0QiLCJyZWNvcmRM b2NhdG9yIjoiVzRLUFlWIiwicGxhdEZvcm0iOiJXZWIiLCJvcmRlcm5vIjpudWxsfQ%3D%3D& user_defined_field=PNR-W4KPYV

3. A check has to be made in the return URL page if the payment was successful or not as in both the cases same return URL will be retrieved.

4. In order to get the booking and payments status within the returnURL page, call the get booking status endpoint.

   Get Booking Status-To get the booking and payments status.

   /api/jz/v1/BookingDetails

   Pass BookingDetailsType value as BalanceDue.

   For successful payment:

   For confirmed bookings and in BookingDetails API response:

   1. Status should be “Confirmed”.

   2. paidStatus should be ”PaidInFull”.

   3. balanceDue should be zero as shown below:

For unsuccessful (Failed) payments:

The BookingDetails API response is as below:

1. Status will be “Hold”.

2. paidStatus will be ”UnderPaid”.

3. balanceDue will be same booking amount.

In case of failure you call the CC payment URL again and enter the valid details for successful booking. If the payment is not successful with in 15min the booking would be cancelled.

1. Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

‌

The following information describes the steps used to make a hold booking using AG Payment. Refer to section 5.2 (Hold Booking) to check the basic and mandatory steps to make a hold booking using AG Payment. Remaining APIs are optional and can be used if needed. Also, for each API, check its corresponding test case (in the test cases file attached to OTA registration email) in- order-to see its request body and the corresponding successful response.

Kindly please refer to section 5.9.2 Booking flow (For AG account) points 1-6.

7 Get Available Hold date – retrieves the recommended hold date if hold is available. Successful

request and response looks similar to the below:

Note: Kindly please note that this hold date should always be greater than 20hrs only then

the hold functionality will be processed.

Since the hold functionality will not be available for few configurable changes (ex: early departure date, certain fares etc.) so kindly please make a check for the Available Hold Date.

8 Add Fee: As the name suggests, it adds hold fee for passengers based on the passenger key. The request body must include the passenger key (obtained by calling GetPassengers API), fee code (HTA), origin of the booking and currency code (Availability response currency code. Successful Add Fee API request and response looks similar to the following:

Note: The Hold service fee (HTA) should be added to all the passengers on the booking.

One way:

• On the journey for all the passengers.

• Ex: KWI-DXB (2 passengers), the HTA fee should be added for all the passengers for KWI- DXB (so all together 2 HTA for 2 passengers with the origin as KWI (origin of the journey)).

  Return:

• On the first journey for all the passengers.

• Ex: KWI-DXB (2 passengers), the HTA fee should be added for all the passengers for KWI- DXB (So all together 2 HTA for 2 passengers with the origin as KWI (origin of the journey)).

  Connecting one way:

• On the journey for all the passengers.

• Ex: KTM-DXB (2 passengers), the HTA fee should be added for all the passengers for KTM- KWI (So all together 2 HTA for 2 passengers with the origin as KTM (origin of the journey)).

  Connecting Return:

• On the first journey for all the passengers.

• Ex: KTM-DXB (2 passengers), the HTA fee should be added for all the passengers for KTM- KWI (So all together 2 HTA for 2 passengers with the origin as KTM (origin of the journey)).

1. Add payment to booking – Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.

   Include the parameter deposit as true.

   Pass the sum of the amount (Hold booking Service Fee) retrieved from get passengers API fees codes as “HTA” for all passengers which was added in the above step.

   Sample Response of get passengers API after adding HTA fee for two passengers

   
   

   Consider the sum of above highlighted amount for all the passengers and pass this to the amount of Add payment request along with deposit flag true as below:

   
   

   Request for Add payment to booking:

   
   

   Response is similar to that of normal booking.

   
   

2. Commit booking – Commits state full changes made and finalize the booking. The amount paid should match to the sum of the amount retrieved from get passengers API fees codes as “HTA” for all passengers.

   Hold booking: Always pass the expiration date retrieved from getavailableholddate API.

   Also add new header parameter confirmHoldBooking and pass it as true for only hold bookings and rest all do not pass any value.

   
   

3. Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

‌

1. Login – Generate token as that of normal booking flow.

2. Retrieve the PNR/Record Locator – Gets a specific booking by record locator and stores it in the state. The API takes Record Locator (PNR) as a parameter. The Successful RetrieveBookingByRecordLocator API response looks similar to the following:

3 Check the balance due - Get Booking Status-To get the balance due

/api/jz/v1/BookingDetails

Pass BookingDetailsType value as BalanceDue.

4 Add Payment to booking - Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.

Adding any paid services need to have corresponding payment added. To pay in full, take amount (balance due) from booking details API and pass it in the Add Payment request.

In Swagger,

Pass AgentID in the Add Payment request header and pass your organization ID as a value for ACCTNO. Over or underpayment is not allowed and committing the booking will not succeed is such case. Successful AddPaymentToBooking APIrequest and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

5 Commit Booking - Commits stateful changes made and finalize the booking. In case of

overpayments or underpayments, commit booking API will not succeed. The amount paid

Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.

Itinerary sending option can be controlled from booking commit request by setting

“notifyContacts”- true/false.

Itinerary sending option is disabled in production and the itinerary emails will be triggered only from TEST environment.

This feature will be enabled the production environment, upon request from the agency. Pass AgentID in the commit booking request header. Successful AddPaymentToBooking API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples). The PNR (recordLocator) will be included the response of this API)

1. Get Booking Status-To get the booking and payments status.

   /api/jz/v1/BookingDetails

   Pass BookingDetailsType value as BalanceDue.

   
   

   For confirmed bookings and in BookingDetails API response:

   1. status should be “Confirmed”.

   2. paidStatus should be ”PaidInFull”.

   3. balanceDue should be zero as shown below:

      
      

2. Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and

response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

5.10 Modify/Cancel Booking Flow

API URL: https://rtestupgrade.jazeeraairways.com/swagger/

Swagger: https://rtestupgrade.jazeeraairways.com/swagger/

Logon information (Token)

The Logon API is used to generate token. It is required the username (agent ID or User ID) and the password to generate the token.

POST  https://rtestupgrade.jazeeraairways.com/api/jz/v1/Token

Request:

{

"credentials": {

"userName": "************", "password": "***********", "domain": "WW2", "channelType": "API"

},

"applicationName": "OTA"

}

Response:

{

"data": {

"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJPVEEiLCJqdGkiOiI1YjJ hYzc4Ni0yZmQ5LTZkNWItY2I1Yi1hZTc1YTVkNjQ1ZjEiLCJpc3MiOiJkb3RSRVogQVBJIn0.j1LL14YrZHJfu htzj9FNlkTIFPtVu5gBXpI0lk_KapQ",

"idleTimeoutInMinutes": 15

}

}

Here the token received from Logon response is required to be passed as the header parameter (Authorization) in all other requests.

Logout

Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it).

DELETE  https://rtestupgrade.jazeeraairways.com/api/jz/v1/Token

Modify Booking Flow:

The API call sequence for modify booking is as follows.

1. Acquire a token (login)

2. Retrieve the booking using PNR/Record locator

3. Rebook search with current booking defaults

4. Booking Quote for new search

5. Delete Journey based on journey key

6. Resell journeys

7. Resell SSR if exists

8. Get Seat Availability

9. Seat Assignment if exists (from the same seat group of the modifying journey(old))

10. Get Booking Details for Balance Due

11. Check Agency account balance

12. Add Payment to booking

13. Commit booking

14. Get booking Details

15. Logout

Cancel Booking Flow:

The API call sequence for cancel booking is as follows.

1. Acquire a token (login)

2. Retrieve the booking using PNR/Record locator

3. Delete Journey based on journey key

4. Get Booking Details for Balance Due

5. Add CS refund to booking (Only AG Mode)

6. Commit booking

7. Get booking Details

8. Logout

MODIFY BOOKING FLOW:

Retrieve the booking using PNR/Record locator:

Endpoint: /api/jz/v1/booking/RetrieveBookingByRecordLocator?RecordLocator=VB3W6N

Gets a specific booking by record locator and stores it in the state. The API takes Record Locator (PNR) as a parameter. The Successful RetrieveBookingByRecordLocator API response looks similar to the following:

In order to modify a journey, we must first delete the current journey and then add the new journey. Identify the journey to be modified and get the journey key.

Rebook search with current booking defaults:

Endpoint: /api/jz/v1/ManageBooking/rebook/availability

Retrieves the flight availability for the new search with the current booking defaults (Only the date can be modified).

Note:

• Only date for the booking can be modified and rest search requests should be same as original booking.

• In case of round trip booking, it is necessary to pass both the inbound & outbound search requests, even if we are changing only one flight.

• Make sure to set the minimum price (minPrice) amount, which is obtained from the corresponding journey segment.

• Original fare amount can be retrieved from Retrieve the booking using PNR/Record locator response – journeys/segment/fares/passengerFares/ (service charges-Type : 0).

• Set the original fare amount as minPrice in the request for rebook availability.

Pass AgentID (UserID) in all the request headers to get the responses.

Booking quote for new search:

Endpoint: /api/jz/v1/BookingQuote

Retrieves fare breakdown, baggage allowance and infant fare based on the request. You will get full value including tax of the each component.

Similar to Normal Booking Quote request.

Pass AgentID (UserID) in all the request headers to get the responses.

Delete Journey based on journey key:

Endpoint: /api/jz/v1/ManageBooking/DeleteJourney?jounrneyKey=Sjl_IDEyn5LV0l_MDE _ Deletes the Journey based on journey key obtained from above step.

Add new header parameter CancelModifyFlag and pass it as modify for modifying the booking.

Also pass AgentID (UserID) in all the request headers to get the responses.

Resell journeys:

Endpoint: /api/jz/v1/ManageBooking/Resell/Trip

Sells the list of journeys and creates a booking if it doesn't already exist.

In case of roundtrips must include only the journeyKey and fareAvailabilityKey for which the modification is being done.

Pass AgentID (UserID) in all the request headers to get the responses.

Note: No of adults, child on the booking journey can be obtained from GetBookingBy PNR & Last name mapping data.passengers (get the sum for each type code and pass it in the below request)

Each adult passenger is associated with "passengerTypeCode": "ADT" Each Child Passenger is associated with "passengerTypeCode": "CHD"

Journey Key, Fare Availability Key, and currency code to be considered from Rebook Availability Response.

This is for 1 adult, 1 child.

{

"keys": [

{

"journeyKey": "Sjl_IDQwM34gfn5LV0l_MDEvMTEvMjAyNCAxODoyNX5IWUR_MDEvMTIvMjAyNCAwMTozNX5_",

"fareAvailabilityKey": "MH5LfiB_Sjl_S0xTUE9XS1d_WEUzMH5_MH45fn5YITA-", "standbyPriorityCode": "",

"inventoryControl": ""

}

],

"passengers": { "types": [

{

},

{

}

],

"residentCountry": "KW"

},

"currencyCode": "KWD", "infantCount": 0, "promotionCode": "",

"sourceOrganization": ""

}

Resell SSR:

Endpoint: /api/jz/v1/ManageBooking/ResellSSR

Resell the SSRs if any SSRs (meals, extra baggage etc) were included in the booking.

Note: Infants on the booking are also considered as SSRS hence kindly please call this resell API request when either or both SSRs and infants are present on the booking response. If neither of them is present please do not Call this API request

Each infant is associated with adult passenger is from GetBookingBy PNR & Last name response mapping data.passengers.{passengerKey}.infant if this is null then infants are not present and if data is present then infants are present on booking. (Please consider the sum for all adult passengers here).

Each SSR is obtained from from GetBookingBy PNR & Last name response mapping data.journeys.segments.passengerSegment.{PassengerKey}.ssrs even if one passenger has SSRS added on the booking Resell SSRs API should be called.

In case of round trip booking, it is necessary to resell SSRS for both the journeys.

Pass AgentID (UserID) in all the request headers to get the responses.

Seats Availability by segment- Endpoint:

/api/jz/v1/SeatsAvailabilityBySegment?segmentkey=Sjl_MDUvMjAyNCAxMDowNX5_

Checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling Re Sell Trip) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:

Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.

The “availability” key is a single digit and it represents the availability of the seat. It may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.

For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.

Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.

Seat Assignment:

Endpoint: /api/jz/v1/seatsAssignment?segmentkey={segmentkey}

In case if seats were assigned for the earlier booking make sure you assign seats for the same seat group.

Note: In order to identify the seat group please consider the GetbookingBy PNR & lastname response mapping data.journeys.segments.passengerSegment.{PassengerKey}.seats[i]. seatInformation.seatSet

Compare the seats availability by segment response for the modified segment with the above seat sets. In case if same seat group or the lowest seat group is available assignment of seat will be free of charge.

Get Booking Details for Balance Due:

Endpoint: /api/jz/v1/BookingDetails (Pass BookingDetailsType value as BalanceDue).

/api/jz/v1/BookingDetails?BookingDetailsType= BalanceDue

Check the balance due - Get Booking Status-To get the balance due.

Check Agency account balance:

Endpoint: /v1/OrganizationsAccount

To make sure the agency account has sufficient account balance to make the payment/booking. The response will contain the below:

Add payment to booking:

Endpoint: /api/jz/v1/Booking/Payment/AddPaymentToBooking

Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.

To pay in full, take amount (balance due) from Get Booking Details for Balance Due and pass it in the Add Payment request

Pass AgentID (UserID) in all the request headers to get the responses.

Commit Booking:

Endpoint:POST /api/jz/v1/Booking/CommitBooking

Commits stateful changes made and finalize the booking. The amount paid should match to the due Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.

Itinerary sending option can be controlled from booking commit request by setting

“notifyContacts” - true/false.

Pass AgentID (UserID) in all the request headers to get the responses.

Get booking From Session:

Endpoint: /api/jz/v1/BookingDetails (Pass BookingDetailsType value as Complete).

/api/jz/v1/BookingDetails?BookingDetailsType=Complete

To get all the details of the booking.

Cancel Booking Flow:

Retrieve the booking using PNR/Record locator:

Endpoint: /api/jz/v1/booking/RetrieveBookingByRecordLocator?RecordLocator=VB3W6N

Gets a specific booking by record locator and stores it in the state. The API takes Record Locator (PNR) as a parameter. The Successful RetrieveBookingByRecordLocator API response looks similar to the following:

In order to cancel a journey, we must first delete the current journey.

Partial cancellation not allowed for the roundtrip booking. In case of roundtrips both the journeys have to be deleted.

Delete Journey based on journey key:

Endpoint: /api/jz/v1/ManageBooking/DeleteJourney?jounrneyKey=Sjl_IDEyn5LV0l_MDE _

Deletes the Journey based on journey key obtained from above step.

Add new header parameter CancelModifyFlag and pass it as cancel for cancelling the booking.

Also pass AgentID (UserID) in all the request headers to get the responses.

Get booking From Session:

Endpoint: /api/jz/v1/BookingDetails (Pass BookingDetailsType value as Complete).

/api/jz/v1/BookingDetails?BookingDetailsType=Complete

The booking must be obtained from the booking in state to receive the outstanding amount after cancellation.

Always consider the first payment key for making the CS Payment.

Add CS payment to booking:

Endpoint: /api/jz/v1/ManageBooking/AddCSPaymentToBooking Update the payment using credit shell account (CS).

For credit shell, take amount (balance due) from Get Booking Details for Balance Due and pass it in the Add Payment request along with the payment key.

Pass AgentID (UserID) in all the request headers to get the responses.

Commit Booking:

Endpoint: PUT /api/jz/v1/Booking/CommitBooking

Commits stateful changes made and finalize the booking. The amount paid should match to the due

Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.

Airline itinerary sending option can be controlled from booking commit request by setting

“notifyContacts” - true/false.

Pass AgentID (UserID) in all the request headers to get the responses.

‌5.11 Service Bundles Feature:

Service Bundles (Ancillary) Flow:

The API call sequence for adding an ancillary on a booking is as follows.

1. Acquire a token (login)

2. Get Availability

3. Sell Flights

4. Get passenger

5. Add Passenger

6. Call Bundle Availability

7. Get details for Bundles such as name to display

8. Add Bundle to booking

9. Get Seat Availability

10. Seat Assignment if exists within the bundle option (for available groups)

11. Get Booking Details for Balance Due

12. Check Agency account balance

13. Add Payment to booking

14. Commit booking

15. Get booking Details

16. Logout

    1. Get Token – Creates the general access token that will grant access to the API. Token idle time out is 15 minutes. That is, the token will expire if idle time between each two consecutive API calls is greater than or equal to 15 minutes.

       Token API should be used wisely as each successful login is associated with one session. Please refer to section 2.1 for best practices regarding session management and avoiding resource leaking.

       Successful Token API request and response looks similar to the following (refer to test cases attached in the organization registration email for full examples including request body and header data (using Postman or Swagger). Agents may require whitelisting server IP address.

       
       

       2. Get Availability – Searches for flights with the full availability search request. This request allows for total control over the configuration or criteria. If a property is not set, default values will be set instead. These defaults are what we consider a general optimized request. If these optimizations are not preferred the requester will need to opt out the filters on the availability request.

       Note: You'll always receive the fares in availability response in origin station default currency regardless of which currency you pass in the request. All the remaining API call requests (BookingQuote, TripSell, BookingCommit, etc) need to use the currency specified in the availability API response. If you want to display fares for customer in any other currency, use currency conversion API.

       Pass AgentID (UserID) in the availability request header to get the availability response. The default values that will be set unless specified:

       • TaxesAndFees = TaxesAndFeesRollupMode.None

       • Criteria.SsrCollectionsMode = AvailabilitySsrCollectionsMode.None

       • Criteria.Filters.FareInclusionType = AvailabilityType.Default

       • Criteria.Filters.CompressionType = FareClassControl.LowestFareClass

       • Criteria.Filters.Loyalty = LoyaltyFilter.MonetaryOnly

       • Criteria.Filters.FlightType = FlightType.All

       • Criteria.Filters.ExclusionType = AvailabilityFilter.ExcludeUnavailable

       • Criteria.Filters.SortOptions =

         JourneySortKey.LowestFare, JourneySortKey.EarliestDeparture, JourneySortKey.ShortestTravelTime

       • Filters.ConnectionType = SoldAsConnectionType.None

       • Criteria.Filters.MaxConnectingFlights = 0

       • Criteria.Stations.SearchDestinationMacs = false

       • Criteria.Stations.SearchOriginMacs = false

       • Criteria.Filters.BundleControlFilter = BundleControlFilter.Disabled

       • NumberOfFaresPerJourney = 1

Successful Availability API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

1. Booking Quote (Price Itinerary) - Retrieves fare breakdown, baggage allowance and infant

   fare based on the request. You will get full value including tax of the each component.

The availability response will only return adult and child fares. When infants are added to a flight search, it is necessary to use the booking quote response to obtain the fares.

Baggage allowance information can also be obtained from the booking quote response.

Pass AgentID in the Booking quote request header to get the response. You can pass one or multiple pairs of journeyKey and fareAvailabilityKey in a single booking quote request. So, round trips, connecting flights or multiple flights can be queried in a single booking quote API request (Ex. for both inbound and outbound flights). Duplicate journeykey is not allowed in a request. Calling this API is optional and not necessarily happens after each availability request unless the information returned by it is required (infants fare, baggage allowance, fare breakdown …etc.).

Note: Although this endpoint behaves like a GET, POST is used to reduce the limitations resulting from URL length issues. Successful BookingQuote API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

1. Trip Sell - Sells the list of journeys and creates a booking if it doesn't already exist. You can sell the infant using this method. Roundtrips must include journeyKey and fareAvailabilityKey of both outbound and return flights in the same API call.

   Pass AgentID in the Trip Sell request header to get the Trip Sell response. Successful TripSell API request and response looks similar to the following:

   
   

2. Get Passengers – Get the collection of passenger(s) on the booking along with passengerkey. Successful GetPassengers API request and response looks similar to the following:

3. Add Passenger and Contact Info (Passengers API) – Update the booking passenger(s) information and contact details based on the passenger key.

Use can use the agency contact information to update the contact details.

Pass AgentID in the Add Passenger and contact request header to get the Add Passenger and contact response. Successful Passengers API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

7. Call Bundle Availability - Retrieves the bundle and ssr availability for the booking in-state.

8. Get Bundles Details based on Bundle Code – Retrives the specific bundles configuration based on the bundle code.

1. Sell Bundles for the Journey –

   Based on the choice for selling the service bundle we can pass only the journey key and bundle code to be applied for all the passengers on the journey.

   
   

   Else if we need to pass it for specific passengers we can pass the passenger Keys along with the bundle code.

   
   

   bundleCode (string): The bundle code to sell.

   passengerKeys (Array[string], optional): A list of passengers to sell the bundle for.

   
   

2. Seats Availability by segment- checks for available seats for a specific segment of a flight. There need to be a booking in the session (calling TripSell) in order to check seats availability. It takes segmentKey (the journeyKey of the segment you wish to assign seat(s) in it) as a parameter as the following:

Check available seats (if the node value is "5" (Open)). It is important to check the “Availability” node in the seat availability API response before assigning the seat as shown below.

The “availability” key is a single digit and it represents the availability of the seat. It may have the following values [0-'Unknown', 1-'Reserved', 2-'Blocked', 3-'HeldForAnotherSession', 4- 'HeldForThisSession', 5-'Open', 6-'Missing', 7-'CheckedIn', 8-'FleetBlocked', 9-'Restricted', 10- 'Broken', 11-'ReservedForPnr', 12-'SoftBlocked', 13-'Unavailable']. Booking a seat will not succeed if seats availability value is not 5.

For roundtrip flights or connecting flights, checking seat availability and assigning a seat should happen for each segment of the flight.

Obtain the unitKey of the available seat you wish to assign to use it in seatsAssignment API.

11. Seat Assignment- As the name suggests, it assigns a seat for a passenger. The API takes

segmentKey (the journeyKey of the journey you wish to assign seat(s) in it) as a parameter. The request body must include the unitkey (obtained by calling get seatsAvailabilityBySegment API) and the passengerkey (obtained by calling GetPassengers API). Successful GetPassengers API request and response looks similar to the following:

12 Check the balance due - Get Booking Status-To get the balance due

/api/jz/v1/BookingDetails

Pass BookingDetailsType value as BalanceDue.

13 Add Payment to booking - Update the payment using Agency account (AG) mode. Account number (ACCTNO) should be the Organization ID.

Adding any paid services need to have corresponding payment added. To pay in full, take amount (balance due) from booking details API and pass it in the Add Payment request.

In Swagger,

Pass AgentID in the Add Payment request header and pass your organization ID as a value for ACCTNO. Over or underpayment is not allowed and committing the booking will not succeed is such case. Successful AddPaymentToBooking APIrequest and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

14 Commit Booking - Commits stateful changes made and finalize the booking. In case of

overpayments or underpayments, commit booking API will not succeed. The amount paid

Confirmed booking: Always check the “balanceDue” parameter in the commit booking response to make sure the booking is confirmed or not. It will be zero for confirmed bookings.

Itinerary sending option can be controlled from booking commit request by setting

“notifyContacts”- true/false.

Itinerary sending option is disabled in production and the itinerary emails will be triggered only from TEST environment.

This feature will be enabled the production environment, upon request from the agency. Pass AgentID in the commit booking request header. Successful AddPaymentToBooking API request and response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples). The PNR (recordLocator) will be included the response of this API)

1. Get Booking Status-To get the booking and payments status.

   /api/jz/v1/BookingDetails

   Pass BookingDetailsType value as BalanceDue.

   
   

   For confirmed bookings and in BookingDetails API response:

   1. status should be “Confirmed”.

   2. paidStatus should be ”PaidInFull”.

   3. balanceDue should be zero as shown below:

   
   

2. Logout- Logout terminates an existing session. Any data that is not committed to the database is lost and all database and system resources associated with the session are released. It is very important to call Logout API when the session is no longer required after check flight availabilities or after finalizing a booking (paying it fully and committing it). API request and

response looks similar to the following (refer to test cases attached to the organization registration email for full APIs examples):

APPENDIX A: GLOSSARY

‌APPENDIX B: ANALYSIS MODELS

‌APPENDIX C: ISSUES LIST

Jazeera Airways, Kuwait

Website: https://www.jazeeraairways.com/